A cellular communications network typically includes a variety of communication nodes coupled by wireless or wired connections and accessed through different types of communications channels. Each of the communication nodes includes respective protocol stacks that process the data respectively transmitted and received over the communications channels. Depending on the type of communications system, the operation and configuration of the various communication nodes can differ and are often referred to by different names. Such communications systems include, for example, a Code Division Multiple Access 2000 (CDMA2000) system and a Universal Mobile Telecommunications System (UMTS).
Third generation wireless communication protocol standards (e.g., 3GPP-UMTS, 3GPP2-CDMA2000, etc.) may employ a dedicated traffic channel in the uplink (UL) (e.g., a communication flow from a mobile station (MS) or User Equipment (UE) to a base station (BS) or NodeB). The dedicated channel may include a data part (e.g., a dedicated physical data channel (DPDCH) in accordance with UMTS Release 4/5 protocols, a fundamental channel or supplemental channel in accordance with CDMA2000 protocols, etc.) and a control part (e.g., a dedicated physical control channel (DPCCH) in accordance with UMTS Release 4/5 protocols, a pilot/power control sub-channel in accordance with CDMA2000 protocols, etc.).
FIG. 1 illustrates a conventional wireless communication system 100 operating in accordance with UMTS protocols. Referring to FIG. 1, the wireless communication system 100 may include a number of NodeBs 110, each serving the communication needs of an user equipment UE 105 in a respective coverage area. The NodeBs 110 are connected to a radio network controller (RNC) 120. RNCs 120 are connected to a core network (CN) 130 including, for example in case of UMTS a Mobile Switching Center (MSC) (not shown) and Serving GPRS Support Node (SGSN) (not shown). The RNC 120 handles certain call and data handling functions, such as, autonomously managing handovers without involving a MSC and SGSN. The MSC and SGSN handle routing calls and/or data to RNCs 120 in the Radio Access Network (RAN) or to a CN 130 including for example, a Gateway GPRS Support Node (GGSN) (not shown), a Policy Decision Function (PDF) (not shown) and an Application Function (AF) (not shown).
FIG. 2 illustrates a conventional wireless communication system operating in accordance with CDMA2000 1xEV-DO protocols. Referring to FIG. 2, the wireless communication system 200 may include a number of base transceiver stations (BTS) 220, each serving the communication needs of mobile stations (MS) 205 in a respective coverage area. The BTSs 220 are connected to a RNC 215. The RNC is connected to a core network (CN) 230, which includes a Packet Data Serving Node (PDSN) (not shown), which is connected to a home Authentication, Authorization and Accounting Server AAA (not shown). BTSs 220 and RNCs 215 of the conventional wireless communication system 200 function similar to their counter parts NodeBs 110 and RNCs 120 in the conventional wireless communication system 100. Likewise, the PDSN of the wireless communication system 200 functions similar to the GGSN and SGSN of wireless communication system 100.
Conventionally, transmission of High Speed Data (HSDPA, EV-DO) is performed via a single BTS 220 or NodeB 110. High speed data is not transmitted from multiple base transceiver stations BTSs 220 to a single MS 205 or multiple NodeBs 110 to a UE 105 because the transmission of high speed data conventionally requires scheduling on each of the BTSs 220 or NodeBs 110 and the scheduling between BTSs 220 or NodeBs 110 is not synchronized.
Conversely, data channel (DCH) traffic (e.g., voice frames) can be transmitted from multiple base stations BTSs 220 or NodeBs 110 as long as the timing of transmitting the voice frames from multiple base stations BTSs 220 or the NodeBs 110 is substantially the same.
Networks used for sending VOIP frames result in variable network delay in the packet arrival to a destination. This variable delay is referred to as jitter. Jitter results in a network for several reasons including: queues in the routers prioritizing packets based on QOS or FIFO; sudden increase and/or decrease in network congestion; LAN collision; etc.
In order to avoid problems stemming from jitter, a conventional end system such as a MS 205 or UE 105 designed to process VOIP frames includes a jitter buffer. The jitter buffer alleviates problems stemming from jitter by queuing VOIP frames and replaying the VOIP frames with the same time spacing that was generated by the source of the frames.
VOIP frames stored in a jitter buffer are processed by the jitter buffer controller using the following fields included in a RTP header: timestamp fields, which indicate when the voice frame needs to be played to the user; and a sequence number field, which is incremented for each transmitted voice frame and allows re-sequencing of the VOIP frames by the jitter buffer controller as is well-known in the art.
A playback mechanism of a jitter buffer is used in a conventional device to playback the VOIP frames stored in the jitter buffer. The playback mechanism checks the sequence number and the timestamp of the packet at the top of the queue at a playback time. The playback mechanism during a playback time proceeds through the queued packets and plays each packet or removes the packet and substitutes a “loss packet playback”. For example, if the packet being processed by the playback mechanism is the “expected packet” as determined based on the sequence number, then the packet is played, whereas if the packet is not the “expected packet” as determined based on the sequence number (i.e., the sequence number of the next packet is larger then the sequence number of the packet that should be played), then the “packet loss playback” mechanism is used as a substitute for the packet. For example, white noise may be used by the “packet loss playback” mechanism and thus, white noise is played as a substitute for a packet that is not the “expected packet”. Once all of the packets queued in the jitter buffer are processed by the playback mechanism, the playback mechanism stops until the next playback time occurs.
As is well-known in the art, the length of the jitter buffer may be static or dynamic and is dependent on the vendor's implementation. Further, as is well-known in the art, the length of the Jitter Buffer is a result of a compromise as explained below.
For example, if the length of the jitter buffer is too short, the jitter buffer will not handle sufficient jitter and packets may be dropped because the jitter buffer is full. Alternatively, if the length of the jitter buffer is too long, the jitter buffer may result in excess delay and may be unsuitable for conducting a conversation using VOIP frames. The length of a conventional jitter buffer typically buffers a number of frames corresponding to approximately 20-80 msec worth of real-time data.